\documentclass{mini}
\usepackage[utf8]{inputenc}
\usepackage{color}
\usepackage[polish, english]{babel}
%------------------------------------------------------------------------------%
\title{Algorithm for the best flight search}
\titleaux{Algorytm poszukiwania najkorzystniejszego połączenia lotniczego}
\author{Karolina Baltyn}
\coauthor{Jakub Górzyński, Grzegorz Pałka}
\supervisor{mgr inż. Agnieszka Jastrzębska}
\tutor{prof. nzw. dr hab. inż. Władysław Homenda}
\type{bachelor}
\discipline{computer science}
\monthyear{july 2013}
\date{\today}
\album{227902}
%------------------------------------------------------------------------------%
\begin{document}
\maketitle
\selectlanguage{english}
\tableofcontents
\chapter*{Abstract}

The strategy of graph traversal is determined by the purpose of a concrete algorithm. For
example, it aims at finding the shortest path between two vertices or at finding the most
optimal path, where the criteria of the best choice might be defined i.e. by weights attached
to graph’s edges. Graph traversal algorithms are widely applied in many real-life
applications, including trip planning. Clearly visible is association between a graph (a set of
vertices connected by edges) and a trip (a journey via certain paths between particular
destinations).

The goal of this bachelor thesis project was to design and implement an application, which
suggests an optimal flight plan between two or more places. End-user chooses start and end
points and mid-stops, if required. Criteria, which are applied to choose the best route are:
\begin{itemize}
\item travel dates,
\item total cost of all flights (the cheaper the better),
\item total distance of the journey (the smaller the better).
\end{itemize}

It was necessary to program such additional functionalities, which calculate alternative
routes. Such facilitating options might be attractive for the end-user, who after seeing these
suggested flights, may change her/his original plans. These alternative routes might be
slightly modifying criteria inputted previously by the end-user, but be more attractive (for
example: the price for a ticket for the next day is ten times cheaper). The application enables
a user to choose criteria (default, price or distance), number of adults and children, return
option etc. Calculation is performed by the web service, which exchanges results with the
client phone application.

The second chapter called Overview is about an idea of technologies and strategies of
programming used in the project. Along with the short description of software development
model, we show the simple use-case diagram to illustrate how the application should work.
Chapter 3 starts with the description of technologies on the client side. Then, we discuss the
application’s structure with regard to classes. Afterwards, the reader can study the various
numbers of tests performed, including test cases, test logs and test scenarios. The chapter
ends with the user manual which consists of numerous graphical aids.

The next section of the documentation informs about the server. It describes methods and
tools used during coding, explains the connection between client and server. What is more,
the chapter contains the illustration of class diagram, all information about databases, and
last but not least number of tests performed during examination of the application.
The last chapter is a summary of the whole paper. There, the reader finds the graphical look
of the application in every action. Moreover, the answers to questions such as what brought
us problems, what we wanted to do but we did not, and what we modified in comparison to
our original ideas can be read. In the last part of the chapter we present our short
conclusions.

\chapter*{Streszczenie}

Strategia przeszukiwania grafu jest uwarunkowana celem konkretnego algorytmu.
Przeszukiwanie ma na celu na przykład znalezienie najkrótszej ścieżki pomiędzy dwoma
wierzchołkami lub znalezienie najbardziej optymalnej ścieżki, gdzie przykładowo kryteria
wyboru mogą być zależne od wag krawędzi. Algorytmy przeszukiwania grafu mają szerokie
zastosowanie w wielu aplikacjach włącznie z planowaniem podróży. Ewidentne jest
powiązanie pomiędzy grafem (zbiorem wierzchołków, połączonych za pomocą krawędzi)
oraz podróżą (przemieszczanie się wyznaczonymi trasami pomiędzy konkretnymi celami
podróży).

Celem niniejszej pracy inżynierskiej było zaprojektowanie i implementacja aplikacji, która
proponuje optymalny plan lotów pomiędzy co najmniej dwoma destynacjami. Użytkownik
wybiera początek i cel podróży oraz ewentualnie punkty pośrednie. Kryteria, zastosowane
do wyboru najlepszego lotniczego połączenia, obejmują:
\begin{itemize}
\item daty podróży, 
\item całkowity koszt wszystkich lotów (im tańsze, tym lepsze),
\item całkowity dystans do przebycia/czas przelotu (im mniejszy, tym lepszy). 
\end{itemize}

Koniecznością było zaprogramowanie dodatkowych funkcjonalności, obliczających
alternatywne połączenia. Ułatwienia tego typu mogą wydać się atrakcyjne dla użytkownika,
który po zapoznaniu się z innymi sugerowanymi lotami może chcieć zmienić swoje
pierwotne plany. Alternatywne połączenia mogą różnić się tych, które użytkownik chciał na
początku uzyskać, lecz mogą okazać się bardziej atrakcyjne pod różnymi względami (na
przykład cena biletu jest niższa). Aplikacja umożliwia użytkownikowi wybór kryteriów
(domyślne, według ceny, według czasu przelotu), liczby dorosłych pasażerów i dzieci, opcję
powrotu itd. Obliczenia wykonywane są przez usługę sieciową, która wysyła wyniki
końcowe do aplikacji klienta.

Drugi rozdział opisuje technologie i strategie programowania, zastosowane w projekcie
pracy inżynierskiej. Razem z krótkim opisem modelu procesu wytwórczego
oprogramowania, ukazany jest prosty diagram przypadków użycia, aby zilustrować
działanie aplikacji.

Rozdział trzeci rozpoczyna się opisem technologii po stronie klienta. Następnie nakreślona
jest struktura klas w aplikacji. Przedstawione są także różnorodne testy, łącznie z
przypadkami testowymi, logami i scenariuszami. Na końcu rozdziału opisana jest instrukcja
działania aplikacji, zawierająca liczne zrzuty ekranu.

Następny rozdział dokumentacji przedstawia rolę serwera. Znajduje się tu opis metod i
narzędzi użytych w trakcie procesu implementacji, wyjaśnia powiązanie między klientem a
serwerem. Ostatni rozdział zawiera także ilustrację przedstawiającą diagram klas,
informacje na temat bazy danych i testy przeprowadzone na serwerze z wykorzystaniem
przykładowych zapytań, wysyłanych przez klienta.

Ostatni rozdział jest podsumowaniem całego projektu. Przedstawia także wygląd końcowy
aplikacji w poszczególnych etapach działania. Rozdział zawiera sekcje dotyczące
problemów, z którymi autorzy pracy musieli się zmierzyć, porzuconych pomysłów i
modyfikacji w stosunku do pierwotnych planów. Ostatnia część dotyczy prezentacji
wniosków.

\chapter*{Introduction}


The strategy of graph traversal is determined by the purpose of a concrete algorithm. For example, it aims at finding the shortest path between two vertices or at finding the most optimal path, where the criteria of the best choice might be defined i.e. by weights attached to graph's edges. Graph traversal algorithms are widely applied in many real-life applications, including trip planning. Clearly visible is association between a graph (a set of vertices connected by edges) and a trip (a journey via certain paths between particular destinations).  

The goal of this bachelor thesis project was to design and implement an application, which suggests an optimal flight plan between two or more places. End-user chooses start and end points and mid-stops, if required. Criteria, which are applied to choose the best route, are:
\begin{itemize}
\item travel dates,
\item total cost of all flights (the cheaper the better),
\item total distance of the journey (the smaller the better). 
\end{itemize}

It was necessary to program such additional functionalities, which calculate alternative routes. Such facilitating options might be attractive for the end-user, who after seeing these suggested flights, may change her/his original plans. These alternative routes might be slightly modifying criteria inputted previously by the end-user, but be more attractive (for example: the price for a ticket for the next day is ten times cheaper).



\chapter{Explanation of the problem}

This chapter of the document introduces the summary of analysis of the whole problem. Moreover, we present and comment the division of work between cooperators. Finally, we discuss the structure of this document as well as important topics covered.

\section{Analysis of the problem}

In a nutshell, the main point of the project was to come across the best possible solution to find the shortest path between two locations. After finding out that we could not use the simplest informed searching (such as Dijkstra or A* algorithms due to unpredictable options in the program, like the time and price of the travel), we decided to go with graph travellers one.

\section{Division of work}

\subsection{Karolina Baltyn}
\begin{enumerate}
\item Coding the webservice.
\item Creating structure of the database.
\item Establishing connection between the database and the webservice.
\item Establishing connection between the Android client and the webservice.
\end{enumerate}

\subsection{Jakub Górzyński}
\begin{enumerate}
\item Providing data for the database.
\item Designing GUI.
\item Coding the client side.
\item Adding new functionalities.
\end{enumerate}

\subsection{Grzegorz Pałka}
\begin{enumerate}
\item Selecting appropriate design patterns.
\item Providing extensibility.
\item Coding the client side.
\end{enumerate}

\section{Chapters}

As we have already mentioned, the first chapter is about explanation of the project. It summarizes the problem and presents the division of work between authors.

The second chapter called Overview is about an idea of technologies and strategies of programming used in the project. Along with the short description of software development model, we show the simple use-case diagram to illustrate how the application should work.

Chapter 3 starts with the description of technologies on the client side. Then, we discuss the application's structure with regard to classes. Afterwards, the reader can study the various numbers of tests performed, including test cases, test logs and test scenarios. The chapter ends with the user manual which consists of numerous graphical aids.

The next section of the documentation informs about the server. It describes methods and tools used during coding, explains the connection between client and server. What is more, the chapter contains the illustration of class diagram, all information about databases, and last but not least number of tests performed during examination of the application.

The last chapter is a summary of the whole paper. There, the reader finds the graphical look of the application in every action. Moreover, the answers to questions such as what brought us problems, what we wanted to do but we did not, and what we modified in comparison to our original ideas can be read. In the last part of the chapter we present our short conclusions.




\chapter{Overview}


\section{Technologies and strategy of programming}

After many discussions about pros and cons regarding the technologies we were going to use in our project, we decided about the best (in our opinions) solution. We found it interesting to join two technologies together: Android and .NET. Because they are very popular nowadays and it is quite easy to join applications that use the same approach, we agreed to mix them. \\
In our project, we were going to develop an Android client application in Java that would enable a user to look for convenient flights. After selecting options interesting for the user and clicking on the “Search” button, it performs a SOAP request to access the server application, which in our case is a web service in ASP.NET. This service contains some methods like GetFlight() with different parameters, depending on the request. However, in order to obtain true flight details, this web service would need to collect data from another web service or web services, which provide such information. Unfortunately, for this project, we had to use an artificially created flight database, due to the fact that such webservices require some payment. Nevertheless, our database contained qualitatively the same information as commercial flight databases, the only difference was in the size of the database. Later it performs necessary calculations, using algorithms and taking into account options chosen by the client. Then it transforms the received data into a proper message that can be sent to Android and easily read.\\
The application contains design patterns (explained later) and provide extensibility.


\section{Software development process model}

As a software development process model we have chosen the Iterative Waterfall Model (see Figure~\ref{fig:waterfallModel}). In this model, rather than finishing a whole phase before moving onto the next one, we split our work into iterations. At the end of each iteration we have reviewed the state of the application, and then after applying necessary modifications, we proceeded with further work. By selecting this representation of software development we are able to make changes in previous phase of the systems development life cycle (SDLC) according to our needs.

\begin{figure}
\centering
\includegraphics[scale=0.6]{graphics/req.jpg}
\caption{Iterative Waterfall Model \cite{waterfall}}
\label{fig:waterfallModel}
\end{figure}



\section{Use-case diagram}

Use case Diagram is a graphical illustration of a communication between a user and the system. Use-case diagram (see Figure \ref{fig:usecaseDiagram}) in UML langauge is used to model the functionality of the system and it is created in the first phases of the project. Use-case diagram is divided into two parts. First part of a diagram shows user's possibilities of interaction with our program, selecting necessary options for particular search. Another part of use-case diagram shows our application and its functions which are responsible for the application to work properly.

\begin{figure}[htbp]
\centering
\includegraphics[scale=1]{graphics/TA.jpg}
\caption{Use-case diagrams}
\label{fig:usecaseDiagram}
\end{figure}


\chapter{Client}

\section{Technologies and strategy of programming}

As mentioned before, the client has been written in Java programming language with use of the Android software development kit that provides the API libraries and developer tools necessary to create applications for Android. 

All graphics used in our project were created with help of Adobe Photoshop program. Nonetheless, the so called graphical user interface of the TripAdvisor has been designed and coded in Eclipse with Android SDK plugin of course.

\section{Class diagram}

\begin{figure}[htbp]
\centering
\includegraphics[scale=1]{graphics/classclient.png}
\caption{Client class diagram}
\label{fig:classclient}
\end{figure}

We have created a simple class diagram (see Figure \ref{fig:classclient}) to show how our classes work and how they are connected to each other. We have four main classes: MainActivity, MainApplicationViewActivity, CommunicationManager, and ResultActivity. Below you will find class diagram and a short discription of those classes.


\textbf{Below you will find a list and a short description of main classes used in our application:}
\begin{itemize}
\item \textbf{MainActivity} - This is a loading page with the logo of our project and progress bar. Progress bar is based on the timer. MainActivity connects to activity\_main.xml where the layout is done.
\item \textbf{ApplicationViewActivity} - This is the most important class of the program. Here the code is responsible for function such as: number of adults, number of children, return option, adding and removing destinations, search arrangement, test buttons, date picking, clearing the site, and of course autocomplete text bars of cities to fly to and from. The layout of class is mainly in activity\_main\_application\_view.xml. This is the class with which the user interacts the most. It was hard to make it function in every case.
\item \textbf{CommunicationManager} - This class is a singleton. This means that it is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. In our case CommunicationManager takes the information inserted into MainApplicationViewActivity and sends them to the server
\item \textbf{ResultActivity} - Inside this class, information are received from the server and being analyzed. Received information about the flights are presented to the user in a nice and clear way to read. The layout of this class is represented in activity\_result.xml

\end{itemize}

\section{Tests}

In this section we will go through a few tests to check if the application works correctly. We will be talking about general tests of our application as a program and also using testing scenarios. General tests of our application will check if correct response is given by the program when certain keys are pressed. Scenario tests will check if the program behaves properly assuming some input options were provided.

\begin{itemize}
\item \textbf{Test cases in general}
Test cases are procedures comprising of single step or more frequently a sequence of steps, to test the correct behaviour, functionality and features of the application. Most of expected results and outcomes are being provided in Business and Technical Analysis of the Group Project. Test cases are performed by the customer who checks if the application works correctly.

\textbf{ID} – the number of test case
\\ \textbf{SCENARIO} – the tested situation
\\ \textbf{USER ACTION} – the user action/input to start case scenario
\\ \textbf{EXPECTED BEHAVIOR} – what should occur when everything done properly

\begin{center}
  \begin{tabular}{ l | p{3cm} | p{3cm} | p{5cm} }
    \hline
    ID & SCENARIO & USER ACTION & EXPECTED BEHAVIOR \\ \hline
    1. & Opening execution file & Click the installed application on your phone & Should display the software’s loading screen\\ \hline
    2. & Change number of passengers & Input number of Adults and Children in the number picker & Form should change to required data \\ \hline
    3. & Choose return option & Check the Return option checkbox & Return option should be checked\\ \hline
    4. & Choose destinations & Click on the white form and input wanted destination & Should display auto completion method and fill out the destination form\\ \hline
    5. & Add destinations & Click the [+] button above the “From:” form & Should add a new destination form underneath the last one\\ \hline
6. & Remove destinations & Click the [-] button above the “From:” form & Should remove the last destination\\ \hline
7. & Choose date & Click the [Date] button and choose your date & Should display a calendar window to choose the date\\ \hline
 
8. & Choose search arrangement & Choose one of three options to select the search arrangement & Chosen option should be selected\\ \hline
9. & Clear data & Click the [CLEAR] button on the left upper side of the application & Should give an initial screen of the software with clear data\\ \hline
10. & Test scenarios & Click one of three [TEST \#] scenarios buttons & Should fill out the form with various data. Some options should be disabled for the user\\ \hline

    
    \
  \end{tabular}
\end{center}

\textbf{Summary}
There have been 10 general tested cases. The testing was performed on three different cell phones with Android operating system, and one Windows compiler in Eclipse with Android SDK. Examination was based mainly on Business/Technical Analysis and on end-user discoveries. After the entire application check, the project is ready for development.

\item \textbf{Test logs}
Test logs are based on the general test cases of the Group Project written in the Test Cases section. The logs show if the test case passed the expectations and if not, it shows the level of wrong occurrence.

 \textbf{ID} – the number of test case
\\ \textbf{ACCEPTANCE} – OK / NOT OK
\\ \textbf{INCIDENT REPORT} – NONE, CRITICAL, MAJOR, MINOR

\begin{center}
  \begin{tabular}{ l | c | r }
    \hline
    ID & ACCEPTANCE & INCIDENT REPORT \\ \hline
    1. & OK & NONE \\ \hline
    2. & OK & NONE \\ \hline
    3. & OK & NONE \\ \hline
    4. & OK & NONE \\ \hline
    5. & OK & NONE \\ \hline
    6. & OK & NONE \\ \hline
    7. & OK & NONE \\ \hline
    8. & OK & NONE \\ \hline
    9. & OK & NONE \\ \hline
    10. & OK & NONE \\ \hline
  \end{tabular}
\end{center}

\textbf{Summary} There have been 10 general tested cases. The testing was performed on three different cell phones and one Windows compiler in Eclipse with Android SDK. Examination shows 0 MINOR, 0 CRITICAL and 0 MAJOR errors.


\item \textbf{Test scenarios}
Besides the test cases for general use of a program, we have written three different test scenarios. The data input and description of each can be read below.
\\ \\ \\ \textbf{TEST 1} \\
\begin{tabular}{ l | r }
\\ \hline
Number of destinations & 4 \\ \hline
Destination 1 (FROM): &	AMSTERDAM\\ \hline
Destination 2:	& WARSAW\\ \hline
Destination 3:	& ROME\\ \hline
Destination 4:	& PARIS\\ \\ \hline

Trip dates:	& 03.02-08.02.2013\\ \hline
Date 1:& 03.02.2013\\ \hline
Date 2:& 05.02.2013\\ \hline
Date 3:& 08.02.2013\\ \\ \hline

Number of passengers:&4\\ \hline
Adults (18+):&2\\ \hline
Children (0-17):&2\\ \\ \hline
 
Return option:&NO\\ \hline
Search by:&PRICE\\ \hline
 
Total price:& ....,.. \\ \hline

\end{tabular}
\\ \\ \\In \textbf{TEST 1} scenario, we want to go to four different cities starting from Amsterdam. After the beginning location is chosen, we select three other destinations such as Warsaw, Rome and Paris. We choose date for each aimed city. We select the number of passengers to 4, 2 parents and 2 children. While choosing the Search arrangement option By price we are aware of the fact that our dates and destinations may not match, as we have chosen. This is because the software will look for the best available trip including entered dates and destinations by price\footnote{For example, to go from Amsterdam to Rome will be cheaper than going from Amsterdam to Warsaw.}. After we omit choosing the return option, after the last flight on 08.02.2013, we have no other flights. By clicking the Search button we see best available connections for our trip with a total price of our trip followed by individual price of every connection.
 

\textbf{TEST 2} \\
\begin{tabular} {l | r}
\\ \hline

Number of destinations & 6 \\ \hline
Destination 1 (FROM): &	STOCKHOLM\\ \hline
Destination 2:	& BERLIN\\ \hline
Destination 3:	& AMSTERDAM\\ \hline
Destination 4:	& PARIS\\ \\ \hline
Destination 5:	& WARSAW\\ \\ \hline
Destination 6:	& ROME\\ \\ \hline

Trip dates:	& 02.02-14.02.2013\\ \hline
Date 1:&02.02.2013\\ \hline
Date 2:&04.02.2013\\ \hline
Date 3:&05.02.2013\\ \hline
Date 4:&10.02.2013\\ \hline
Date 5:&12.02.2013\\ \hline
Date 6:&14.02.2013\\ \\ \hline

Number of passengers:&4\\ \hline
Adults (18+):&4\\ \hline
Children (0-17):&0\\ \\ \hline
 
Return option:&YES\\ \hline
Search by:&DISTANCE\\ \hline
 
Total price:& ....,.. \\ \hline

\end{tabular}

In \textbf{TEST 2} scenario we want to go to six different cities starting from Stockholm. After the beginning location is chosen, we select five other destinations such as Berlin, Amsterdam, Paris, Warsaw and Rome. We choose dates for each aimed city. We select the number of passengers to 4 parents. While choosing the Search arrangement option By distance we are aware of the fact that our dates and destinations may not match as we have chosen. This is because the software will look for the best available trip including entered dates and destinations by distance\footnote{For example, to go from Stockholm to Paris will take less time than going from Stockholm to Berlin.}. After we choose the return option, after the last flight on 14.02.2013, we go back to initial destination (Stockholm). By clicking the Search button we see best available connections for our trip with a total price of our trip followed by individual price of every connection.



\textbf{TEST 3} \\
\begin{tabular} { l | r }
\\ \hline

Number of destinations:&3\\ \hline
Destination 1 (FROM):&WARSAW\\ \hline
Destination 2:&STOCKHOLM\\ \hline
Destination 3:&PARIS\\ \hline

Trip dates:&01.02-05.02.2013\\ \hline
Date 1:&01.02.2013\\ \hline
Date 2:&05.02.2013\\ \\ \hline

Number of passengers:&1\\ \hline
Adults (18+):&1\\ \hline
Children (0-17):&0\\ \\ \hline
 
Return option:&NO\\ \hline
Search by:&DEFAULT\\ \hline
 
Total price:& ....,.. \\ \hline

\end{tabular}

In \textbf{TEST 3} scenario, we want to go to three different cities starting from Warsaw. After the beginning location is chosen, we select two other destinations such as Stockholm and Paris. We choose date for each aimed city. We select the number of passengers to 1. While choosing the Search arrangement option By default we are aware of the fact that our dates and destination order will be the same as we have chosen. This is because the software will look for the best available trip including entered dates and destinations by default\footnote{User chooses the order of destinations from the top to bottom.}. After we omit choosing the return option, after the last flight on 05.02.2013, we have no other flights. By clicking the Search button we see best available connections for our trip with a total price of our trip followed by individual price of every connection.



\end{itemize}

\section{Designed interface - user manual}
\begin{enumerate}
\item \textbf{Choosing number of passengers}
- To choose number of Adults and Children, user simply puts required number in the pickers:
\begin{figure}[htbp]
\caption{Default:  1 (Adults) 0 (Children)}
\centering
\includegraphics[scale=1]{graphics/Number.png}
\end{figure}


\item \textbf{Choosing “FROM” destination}
-To choose the beginning location of the trip, user enters name of the city in the “FROM” destination form
\begin{figure}[htbp]
\caption{Default:  NONE}
\centering
\includegraphics[scale=1]{graphics/from.png}
\end{figure}

\item \textbf{Choosing “TO” destination}
-To choose the next location of the trip, user enters name of the city in the “TO” destination form

\begin{figure}[htbp]
\caption{Default:  NONE}
\centering
\includegraphics[scale=1]{graphics/to.png}
\end{figure}

\textbf{Autocomplete method shows completion suggestions automatically while the user is typing the beginning of the city’s name}
\begin{figure}[htbp]
\centering
\includegraphics[scale=1]{graphics/autocomp.png}
\end{figure}
\item \textbf{Choosing date}
-To choose the date of the flight, user simply clicks the Date button.
\centering
\includegraphics[scale=1]{graphics/date.png}



\raggedright
After that, the software displays additional window where user chooses date.

\centering
\includegraphics[scale=0.4]{graphics/chdate.png}

\raggedright
\item \textbf{Adding/Removing destinations}
-To choose more destinations, user simply presses the ADD (+) button, while to remove unnecessary destinations,
user simply presses the REMOVE (-) button.

\centering
\includegraphics[scale=1]{graphics/+-.png}

\raggedright
\item \textbf{Returning option}
-To choose the return option, user simply checks the Return option checkbox

\centering
\includegraphics[scale=1]{graphics/return.png}

\raggedright
\item \textbf{Searching by option}
-To choose the search arrangement, user simply chooses his selection by clicking in one of the available options


\centering
\includegraphics[scale=1]{graphics/searchby.png}

\raggedright
\item \textbf{Clearing data}
-To clear all the data, user simply presses the Clear button in the left upper corner of the application

\centering
\includegraphics[scale=1]{graphics/clear.png}

\raggedright
\item \textbf{Testing scenarios}
-To test one of three available testing scenarios the user clicks the TEST \# button.

\begin{figure}[htbp]
\centering
\includegraphics[scale=1]{graphics/tests.png}
\end{figure}


\item \textbf{Searching for the flights}
-After all the data is filled; the user simply clicks the Search button. Below you can see the example of it.

\centering
\includegraphics[scale=1]{graphics/test1.png}
\raggedright
\end{enumerate}



\chapter{Server}


\section{Technologies and strategy of programming}
This chapter will be devoted to the server-side part of the Trip Advisor. \\
A common design pattern that may be found in the code is Strategy. The strategy pattern defines a family of algorithms, encapsulates each one and makes it possible to interchange them. Strategy lets the algorithm vary independently from clients that use it. This is used in choosing a sorting algorithm. If the user wants to search the flights by price or distance, the algorithms will be chosen by the client who uses the interface. The code will find and work on the algorithm that satisfies the clients need.

\begin{figure}[h!]
  \centering
\includegraphics[scale=0.8]{graphics/strategy.png}
\caption{Strategy pattern scheme \cite{strategy}}
\end{figure}

In the server we used the following softwares and technologies:
\begin{itemize}
\item .NET Technology,
\item Microsoft Visual Studio 2010,
\item SQL Server Management Studio,
\item Doxygen,
\item Linq to Excel library,
\item ksoap2-android library.
\end{itemize}

\section{Client-server connection}
The connection between the client and server is done with the use of SOAP. We used a third-party project called ksoap2-android, which provides a lightweight and efficient SOAP client library for the Android platform. The only drawback of this library is its settings in AndroidManifest.xml file. It is required that the minimal SDK version is set to 8, because it does not work otherwise. It may cause problems with the use of brand new layout components for the recent SDK versions, as they do not work with the early SDK. 

\section{Class diagram}

%\includegraphics[scale=0.95]{graphics/ClassDiagram.png} 

\begin{figure}
\centering
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{graphics/ClassDiagram.png}
\caption{Server class diagram}
\label{fig:serverClassDiagram}
\end{figure}



The server (see Figure~\ref{fig:serverClassDiagram}) consists of classes shown in the diagram. Below we describe each class and its most important components:
\begin{itemize}
\item \textbf{Service} - this is the web service class, responsible for communication with a client application. When the TripAdvisor client connects to the service, it invokes GetFlights method from this class. It is the only method that can be called by client. The whole server is coordinated by Service class.
\item \textbf{Request} - encapsulates a proper request from a client.
\item \textbf{Flight} - encapsulates information about flights from the database and client’s request.
\item \textbf{IAlgorithm} - an interface for concrete algorithm for searching flights. Execute() is a method that needs to be called in order to start calculations.
\item \textbf{DefaultAlgorithm} - a concrete algorithm implementing IAlgorithm interface. 
\item \textbf{PriceAlgorithm} - a concrete algorithm implementing IAlgorithm interface. 
\item \textbf{DistanceAlgorithm} - a concrete algorithm implementing IAlgorithm interface. 
\item \textbf{XmlParser} - parses a client’s XML request to Flight or Request objects, as well as Flights to XML response. It is a static class.
\item \textbf{Converter} - converts (sets of) objects into different (sets of) objects. For now, there is a possible conversion from a DataTable object of flight information into a list of Flight objects.
\end{itemize}
With the code of the project, there is a visual html documentation attached, created with the use of Doxygen. It can be found and opened in Documentation -$>$ Server -$>$ index.html.

\section{Flight algorithms}
This section will describe the algorithms used for finding the best flight combinations. The criteria that a user may choose contain:
\begin{enumerate}
\item Default - The default algorithm looks for flights in the database, keeping the original order from the request. If a client asks for flights from Warsaw to Paris, Berlin and Amsterdam, the DefaultAlgorithm checks connections for Warsaw -$>$ Paris, Paris -$>$ Berlin and Berlin -$>$ Amsterdam. The default algorithm does not actually calculate anything, but it chooses the destinations and dates just in the order.
\item Price - The price algorithm looks for flights in the database, ignoring the original order from the request, but choosing the cheapest connections. Only the initial city (FROM) is always kept at first position. If a client asks for flights from Warsaw to Paris, Berlin and Amsterdam, the PriceAlgorithm checks connections for Warsaw -$>$ Paris/Berlin/Amsterdam and later to the remaining cities. This algorithm uses a modified depth - first search approach. The modification is connected to pruning some nodes - if a current result is worse than the best one so far, the node is discarded. In this way there are no unnecessary calculations performed. 
\item Distance - The distance algorithm looks for flights in the database, ignoring the original order from the request, but choosing the shortest (with respect to time) connections. Only the initial city (FROM) is always kept at first position. If a client asks for flights from Warsaw to Paris, Berlin and Amsterdam, the DistanceAlgorithm checks connections for Warsaw -$>$ Paris/Berlin/Amsterdam and later to the remaining cities. The algorithm used in this case is the same as in the previous example.
\end{enumerate}
We have up to seven cities in our possible trip: one departure city and up to six arrival cities. For each next flight we have one date to choose. If the return option is checked, there is one additional date which is the date of return to the departure city. \\
Below there is a pseudocode of the modified depth-first search algorithm (for the price option):\\ \\
Date = departure date\\
BestPrice = 0\\
BestFLights = empty list\\
ReturnDate = return date\\
City = departure city\\
List = list of possible connections\\
\begin{tabbing}
For \= each flight beginning in City on Date: \\
\> Add flight to List (if exists)\\
\> For \= each pair of remaining cities\\
\>\> For \= each date apart from Date and ReturnDate\\
\>\>\> Add flight to List (if exists)\\
\> If \= return option is checked\\
\>\> Add flight (on ReturnDate to City) to List\\
execute runAlgorithm() function\\ \\

function runAlgorithm():\\
For \= each flight from City on Date\\
\> execute checkSubtree() function \\ \\

function checkSubtree()\\
Calculate the total price of the checked subtree\\
If \= this is the maximum depth\\
\> If \= this price is better than BestPrice\\
\>\> Assign the current price to BestPrice\\
\>\> Assign the current flights list to BestFlights\\
\> return\\
If \= this price is already worse than BestPrice\\
\> return\\
Neighbors = possible destinations on the current date from current city to a city different \\ than those which where already examined\\
For \= each neighbor in Neighbors\\
\> Add neighbor to the list of current flights\\
\> execute recursively checkSubtree() function\\
\end{tabbing}

\begin{figure}
\centering
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{graphics/algorithm.png}
\caption{Algorithm scheme}
\label{fig:algorithm}
\end{figure}
Figure~\ref{fig:algorithm} depicts a scheme of the algorithm's performance.

\section{Database}

\begin{figure}
\centering
\includegraphics[scale=1]{graphics/DatabaseTableDiagram.png}
\caption{Database table diagram}
\label{fig:databaseDiagram}
\end{figure}

The database (see Figure~\ref{fig:databaseDiagram}) is created in SQL Server 2008 and consists of two tables: Flights and Airlines. They are connected by the id in Airlines, which is a foreign key in Flights. It is the simplest database, but it is not needed to make it more complicated for the purpose of this application.\\
The connection between the webservice and the database is done via a connection string defined in Web.config file, an SQL command encapsulated in SqlCommand object and transformed into a DataSet by SqlDataAdapter.

\section{Tests}
In this section we are going to describe tests performed on the server side, separately from the client. Because it is impossible to make tests for both of them in code, then we assumed that the input in server tests is just an example of an xml request from the client.
 
The tests below are unit test, placed in code of the web service. They test several cases of a client’s xml request. Each test is a comparison of an expected value for a given client’s request and a real answer that comes from calculations on the server. The expected value was calculated manually and by debugging the service. The Assert.AreEqual method was used to compare those two strings and therefore find out if the test is a pass or a fail.

\begin{enumerate}
\item \textbf{DefaultOptionTest1} - testing the default algorithm option with one way flight at 01.02.2013 from Warsaw to Amsterdam, for two adults and one child. The second date, which is 05.02.2013 is not taken into account in this case, because a return flight is not requested.\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Default"} {\color{red}return=}{\color{blue}"false"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"1"}$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Amsterdam"} {\color{red}date=}{\color{blue}"05-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}} 
Expected xml string:
\textit{\begin{tabbing}$<$Flights\=$>$\=\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-01 10:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-01 12:00:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Warsaw"} {\color{red}cityTo=}{\color{blue}"Amsterdam"} {\color{red}airline=}{\color{blue}"KLM"} {\color{red}price=}{\color{blue}"80"}/$>$\\
$<$/Flights$>$\end{tabbing}}

\item \textbf{DefaultOptionTest2} - testing the default algorithm option with return and a few flights: from Warsaw to Amsterdam on 05.02.2013, from Amsterdam to London on 07.02.2013, from London to Madrid on 08.02.2013, from Madrid to Berlin on 10.02.2013 and from Berlin to Paris on 13.02.2013.\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Default"} {\color{red}return=}{\color{blue}"true"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"3"}$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Amsterdam"} {\color{red}date=}{\color{blue}"05-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"London"} {\color{red}date=}{\color{blue}"07-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Madrid"} {\color{red}date=}{\color{blue}"08-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Berlin"} {\color{red}date=}{\color{blue}"10-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Paris"} {\color{red}date=}{\color{blue}"13-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected xml string:
\textit{\begin{tabbing}$<$Flights\=$>$\=\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-01 10:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-01 12:00:00"}\\
\>\>{\color{red}cityFrom=}{\color{blue}"Warsaw"} {\color{red}cityTo=}{\color{blue}"Amsterdam"} {\color{red}airline=}{\color{blue}"KLM"} {\color{red}price=}{\color{blue}"120"}/$>$\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-05 10:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-05 12:00:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"Amsterdam"} {\color{red}cityTo=}{\color{blue}"London"} {\color{red}airline=}{\color{blue}"KLM"} {\color{red}price=}{\color{blue}"247"}/$>$\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-07 15:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-07 19:00:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"London"} {\color{red}cityTo=}{\color{blue}"Madrid"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"97"}/$>$\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-08 10:05:00"} {\color{red}dateTo=}{\color{blue}"2013-02-08 12:30:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"Madrid"} {\color{red}cityTo=}{\color{blue}"Berlin"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"217"}/$>$\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-10 21:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-10 22:10:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"Berlin"} {\color{red}cityTo=}{\color{blue}"Paris"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"205"}/$>$\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-13 19:25:00"} {\color{red}dateTo=}{\color{blue}"2013-02-13 21:30:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"Paris"} {\color{red}cityTo=}{\color{blue}"Warsaw"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"155"}/$>$\\
$<$/Flights$>$\end{tabbing}}



\item \textbf{PriceOptionTest1} - testing the price algorithm option with no return and only one flight: from Warsaw to Amsterdam on 01.02.2013. The second date, which is 05.02.2013 is not taken into account in this case, because a return flight is not requested.\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Price"} {\color{red}return=}{\color{blue}"false"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"1"}$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Amsterdam"} {\color{red}date=}{\color{blue}"05-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected xml string:
\textit{\begin{tabbing}$<$Flights\=$>$\=\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-01 10:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-01 12:00:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Warsaw"} {\color{red}cityTo=}{\color{blue}"Amsterdam"} {\color{red}airline=}{\color{blue}"KLM"} {\color{red}price=}{\color{blue}"80"}/$>$\\
$<$/Flights$>$\end{tabbing}}



\item \textbf{PriceOptionTest2} - testing the price algorithm option with return and a few flights. The city of departure and final arrival (return) is Warsaw. The algorithm assumes that other cities chosen, i.e. Amsterdam, London, Madrid, Berlin and Paris do not have to appear in the given order. However, the dates of flights must stay the same: departure at 01.02.2013, then at 05.02.2013, 07.02.2013, 08.02.2013, 10.02.2013 and return flight at 13.02.2013. \\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Price"} {\color{red}return=}{\color{blue}"true"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"3"}$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Amsterdam"} {\color{red}date=}{\color{blue}"05-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"London"} {\color{red}date=}{\color{blue}"07-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Madrid"} {\color{red}date=}{\color{blue}"08-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Berlin"} {\color{red}date=}{\color{blue}"10-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Paris"} {\color{red}date=}{\color{blue}"13-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}

Expected xml string:
\textit{\begin{tabbing}$<$Flights\=$>$\=\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-01 10:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-01 12:00:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Warsaw"} {\color{red}cityTo=}{\color{blue}"Amsterdam"} {\color{red}airline=}{\color{blue}"KLM"} {\color{red}price=}{\color{blue}"120"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-05 11:15:00"} {\color{red}dateTo=}{\color{blue}"2013-02-05 11:50:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Amsterdam"} {\color{red}cityTo=}{\color{blue}"Berlin"} {\color{red}airline=}{\color{blue}"KLM"} {\color{red}price=}{\color{blue}"82"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-07 21:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-07 22:10:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Berlin"} {\color{red}cityTo=}{\color{blue}"Paris"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"205"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-08 15:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-08 16:30:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Paris"} {\color{red}cityTo=}{\color{blue}"London"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"210"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-10 15:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-10 19:00:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"London"} {\color{red}cityTo=}{\color{blue}"Madrid"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"72"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-13 17:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-13 20:00:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Madrid"} {\color{red}cityTo=}{\color{blue}"Warsaw"} {\color{red}airline=}{\color{blue}"LOT"} {\color{red}price=}{\color{blue}"56"}/$>$\\
$<$/Flights$>$\end{tabbing}}



\item \textbf{DistanceOptionTest1} - testing the distance (in time) algorithm option with no return and only one flight: from Warsaw to Amsterdam on 01.02.2013. The second date, which is 05.02.2013 is not taken into account in this case, because a return flight is not requested.\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Distance"} {\color{red}return=}{\color{blue}"false"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"1"}$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\>$<$Flight {\color{red}from=}{\color{blue}"Amsterdam"} {\color{red}date=}{\color{blue}"05-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected xml string:
\textit{\begin{tabbing}$<$Flights\=$>$\=\\
\>$<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-01 10:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-01 12:00:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Warsaw"} {\color{red}cityTo=}{\color{blue}"Amsterdam"} {\color{red}airline=}{\color{blue}"KLM"} {\color{red}price=}{\color{blue}"80"}/$>$\\
$<$/Flights$>$\end{tabbing}}



\item \textbf{DistanceOptionTest2} - testing the distance algorithm option with return and a few flights.\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Distance"} {\color{red}return=}{\color{blue}"true"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"3"}$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Amsterdam"} {\color{red}date=}{\color{blue}"05-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"London"} {\color{red}date=}{\color{blue}"07-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Madrid"} {\color{red}date=}{\color{blue}"08-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Berlin"} {\color{red}date=}{\color{blue}"10-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Paris"} {\color{red}date=}{\color{blue}"13-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected xml string:
\textit{\begin{tabbing}$<$Flights\=$>$\=\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-01 10:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-01 12:00:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Warsaw"} {\color{red}cityTo=}{\color{blue}"London"} {\color{red}airline=}{\color{blue}"LOT"} {\color{red}price=}{\color{blue}"235"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-05 15:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-05 16:00:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"London"} {\color{red}cityTo=}{\color{blue}"Amsterdam"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"140"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-07 15:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-07 15:30:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"Amsterdam"} {\color{red}cityTo=}{\color{blue}"Paris"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"145"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-08 15:00:00"} {\color{red}dateTo=}{\color{blue}"2013-02-08 16:30:00"}\\
\>\> {\color{red}cityFrom=}{\color{blue}"Paris"} {\color{red}cityTo=}{\color{blue}"Madrid"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"210"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-10 10:05:00"} {\color{red}dateTo=}{\color{blue}"2013-02-10 12:30:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"Madrid"} {\color{red}cityTo=}{\color{blue}"Berlin"} {\color{red}airline=}{\color{blue}"Ryanair"} {\color{red}price=}{\color{blue}"231"}/$>$\\
\> $<$Flight {\color{red}dateFrom=}{\color{blue}"2013-02-13 09:05:00"} {\color{red}dateTo=}{\color{blue}"2013-02-13 10:00:00"}\\ 
\>\> {\color{red}cityFrom=}{\color{blue}"Berlin"} {\color{red}cityTo=}{\color{blue}"Warsaw"} {\color{red}airline=}{\color{blue}"Lufthansa"} {\color{red}price=}{\color{blue}"155"}/$>$\\
$<$/Flights$>$\end{tabbing}}



\item \textbf{NoFlightsTest1} - testing the case when the date of a requested flight is not available in the database\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Default"} {\color{red}return=}{\color{blue}"true"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"1"}$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Amsterdam"} {\color{red}date=}{\color{blue}"17-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected string:\\
\textit{{\color{blue}"No flights found"}}



\item \textbf{NoFlightsTest2} - testing the case when the city of a requested flight is not in the database\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Default"} {\color{red}return=}{\color{blue}"true"} {\color{red}adults=}{\color{blue}"2"} {\color{red}children=}{\color{blue}"1"}$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Utrecht"} {\color{red}date=}{\color{blue}"13-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected string:\\
\textit{{\color{blue}"No flights found"}}

\item \textbf{NoFlightsTest3} - testing the case when the number of adults is too big\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Default"} {\color{red}return=}{\color{blue}"true"} {\color{red}adults=}{\color{blue}"9"} {\color{red}children=}{\color{blue}"1"}$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"London"} {\color{red}date=}{\color{blue}"13-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected string:\\
\textit{{\color{blue}"No flights found"}}

\item \textbf{NoFlightsTest4} - testing the case when the number of children is too big\\
Tested xml string:
\textit{\begin{tabbing}$<$Flights \= {\color{red}option=}{\color{blue}"Price"} {\color{red}return=}{\color{blue}"true"} {\color{red}adults=}{\color{blue}"3"} {\color{red}children=}{\color{blue}"5"}$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"Warsaw"} {\color{red}date=}{\color{blue}"01-02-2013"}/$>$\\
\> $<$Flight {\color{red}from=}{\color{blue}"London"} {\color{red}date=}{\color{blue}"13-02-2013"}/$>$\\
$<$/Flights$>$\end{tabbing}}
Expected string:\\
\textit{{\color{blue}"No flights found"}}

\end{enumerate}
We conducted all the tests described above and all of them resulted according to our expectations. This means that the algorithms work properly. The results show that all tests give a positive answer, i.e. “Passed”.


\chapter{Summary}


\section{Final appearance}
In this section, we show the final appearance of the project. Beyond each screenshot of a program, we place a description of what it represents. Also, we have created a demo video (attached to this documentation) to show how our application is used.


Our data base consists of following information: DateFrom, TimeFrom, DateTo, TimeTo, CityFrom, CityTo, Airline, Price, PriceChildren, Adults, and Children. For each flight all those information must be filled out for the program to work correctly. This is how the database looks like.\\
\includegraphics[scale=1]{graphics/dbb.png}\\
\textbf{Loading screen}

This is the initial screen that we see after launching the program.\\ \\
\includegraphics[scale=1]{graphics/f1.png}


\textbf{Main screen}

This is the Main screen of the software.\\
\includegraphics[scale=1]{graphics/f2.png}

\textbf{Result screen}

This is the Result screen with two destinations.

\includegraphics[scale=1]{graphics/f3.png}


This is the Result screen with more destinations (including scroll)

\includegraphics[scale=1]{graphics/f4.png}



\section{ Project post-mortem}

\subsection {What brought us problems}
To get more from the Group Project, we decided to write our application in Android system. It was our first attempt working with this technology. Therefore, it was hard to omit difficulties. However, we managed to overcome several problems and in general we are happy with the final application.\\
One of the problems was to design a good looking software. Because of the fact that the arrangement of the items such as buttons and layout could not be done using mouse pointers, we were forced to do everything in XML code.\\
From the server side, a major problem for us was launching the Web Service in LAN instead of localhost. Windows security by default does not allow connecting websites placed in IIS from the local network. To enable this feature, we needed to set an exception for our website. Another difficulty was the compatibility of the database file format with other programs installed. Because at the beginning we were using a .xls file to store flight information, we had to install a special program which enables reading Microsoft Office files on the server.

\subsection {What we wanted to do but we did not}
Due to the time limit and problems we encountered while making this project, we resigned from some features that we originally intended to have in our program. We also found out that those features were quite unnecessary and would not really change how the program works.
\begin{enumerate}
\item Amount of stops (when a passenger is not indicating (s)he would like to have a break in-between the flights, the program should plan a route, which involves the minimum amount of stops),
\item The amount of different flight-operators (the fewer the better).
\item Baggage type
\item Class of a flight
\item Range of prices
\item -/+ 2days option
\end{enumerate}

\subsection {What we modified in comparison to our original ideas}
As mentioned before, we have slightly changed the functionalities of the program. However, the changes did not diminish the purpose of it. Options such as selection of the class of a flight or luggage type were not necessary. With them, the only thing that would change would be the total price of a trip. In addition, the scratch design of application is different than our final one.\\
We also modified the searching algorithms. At the beginning we thought it would be a good idea to use informed searching like A* or Dijkstra. However, while implementing the server, it became obvious that prices and travel time is impossible to be predicted. In the first case it’s impossible because the prices vary and there is no rule about it, as it depends on too many factors like airlines, time of the year, current situation in the world, travel time. We had to test every single path leading to the destination in order to say which one is the cheapest. However, what we simplified in our searching tree was that we cut off the branches which price is already bigger than our temporary best result, so that the algorithm does not examine every node. The same applies to the shortest travel time option. It depends on the distance between cities, which we are not given from any flight information provider, and also it depends on the plane as well as the number of stops, which we do not know before examining a particular node.\\
Moreover, at the beginning we decided to have an artificial database in .xls file. However, as we noticed, the performance of such a solution was worse than expected. We needed to install additional software to enable this communication, which turned out to be too slow anyway. In such a case, excel was replaced with the traditional SQL Server database.\\
Finally, we changed the division of work among the members of our group, because it was just easier and better if everyone did the part s/he enjoyed the most. At the beginning our division of work was as follows:\\

\begin{itemize}
\item \textbf{Jakub Górzyński} \\
Preparation and coding of the frame client and server applications, 
which would be responsible for information exchange and presentation.

\item \textbf{Grzegorz Pałka} \\
Conceptual and physical preparation and programming of algorithms for solving stated problem. Algorithms should be finding optimal flight connections. Student should consider existing graph traversal algorithms.

\item \textbf{Karolina Baltyn} \\
Preparation and coding of algorithm’s facilitating features, including searches for alternative routes. Preparation of nontrivial test data ideally based on real-life flight information (including timetables and pricing lists). 

\end{itemize}

The final division of work is presented in chapter 1.2.


\section{Conclusions}

Our Bachelor thesis project’s aim was to create an Android application that does not exist or is really hard to get. There are many flight companies offering an application to help us find flight connection from one place to another, but not to multiple places - that was the main idea and a novelty of our project. With our application the user can select a few places (s)he wants to visit with different dates. This idea would help users in travelling around all Europe using one search result. This is how our application differs from other existing applications. Program is based on Java language for Androids and the server is written using C\#. We think that this project might be a big success comparing it to the simple flight search applications and it can help many users that love to travel. This project is worth developing further. 


  \begin{thebibliography}{1}

  \bibitem{strategy} Strategy pattern scheme, \\
  www.oodesign.com/strategy-pattern.html

  \bibitem{ksoap21} Explanation of an android - webservice connection, \\
  http://www.mobilelx.com/blog/2011/07/tutorial-how-to-communicate-with-a-net-web-service-from-android-using-ksoap2-part-1-of-2/

  \bibitem{ksoap22} Explanation of an android - webservice connection, \\
  http://android.vexedlogic.com/2011/04/17/android-lists-iv-accessing-and-consuming-a-soap-web-service-i/

  \bibitem{serviceConsume} Consuming a webservice in Android, \\
  http://www.craigsprogramming.com/2011/03/tutorial-consume-any-web-service-using.html
  
  \bibitem{msdn} Any help with webservices in .NET,\\
   http://msdn.microsoft.com/en-US/
  
  \bibitem{waterfall} Iterative Waterfall Model, \\
  http://compsci.ca
  
  \end{thebibliography}

\appendix

\chapter{Requirements and installation}
Appendix A is devoted to proper installation and launching of the application and the webservice in the LAN network.
\section{Requirements}

\subsection{Server}
In order to launch the server properly, the following components must be installed:
\begin{itemize}
\item Microsoft Visual Studio 2010,
\item Microsoft .NET Framework 4.0 and 3.5,
\item Internet Information Services (IIS).
\end{itemize}

\subsection{Database}
In order to launch the database properly, the following components must be installed:
\begin{itemize}
\item Microsoft SQL Server 2008,
\begin{itemize}
\item SQL Server Management Studio.
\end{itemize}
\end{itemize}

\subsection{Client}
In order to launch the client properly on the computer, the following components must be installed:


Android Developer Tools version 22.0.1v201305230001—685705 at minimum
To which ADT Package should include:
\begin{itemize}
\item Android DDMS,
\item Android Development Tools,
\item Android Hierarchy Viewer,
\item Android Native Development Tools,
\item Android Traceview,
\item Eclipse EGit,
\item Eclipse Help System,
\item Eclipse Java Development Tools,
\item Eclipse Platform,
\item Eclipse RCP,
\item Eclipse XML Editors and Tools,
\item Equinox p2 Provisioning for IDEs,
\item Tracer for OpenGL ES,
\item WST Common Core,
\item WST Common UI,
\item WST XML Core.
\end{itemize}

In order to launch the client properly on the phone, the following components must be installed on the phone:
\begin{itemize}
\item Android OS (recommended version 2.3.5),
\item AppInstaller Version: 1.0.7 at minimum.
\end{itemize}





\section{Installation}

\subsection{Server}
After installing all the necessary software, please open Microsoft Visual Studio as an administrator. Then, open the project of the given webservice via File-$>$Open. \\
Now we will set the service to run in localhost. Right-click on FlightService project (not solution) and click Properties. In Web tab scroll down up to Servers section (see Figure~\ref{fig:serviceNameProperties}). Select the "Use local IIS Server" option and set the address of your service on localhost: http://localhost/name-of-the-service. 
The website should now appear in Internet Information Services Manager (IIS Manager) in Sites folder, under Default Web Site. If it is not started yet, click on it and press Start.
A common problem with the webservice brings the fact that Windows Firewall is blocking any requests from the outside. Therefore, even though the requests may work well on the same computer, communication between the server and Android client would be impossible. In order not to turn the whole firewall off, go to Windows Firewall with Advanced Security and set Inbound Rules for the port 80, on which the service will be run by default (see Figure~\ref{fig:inboundRules}).  

\begin{figure}
\centering
\includegraphics[scale=1]{graphics/serviceNameProperties.png} 
\caption{Setting the service's address in LAN}
\label{fig:serviceNameProperties}
\end{figure}

\begin{figure}
\centering
\includegraphics[scale=0.8]{graphics/InboundRules.png} 
\caption{Setting inbound rule for the port 80}
\label{fig:inboundRules}
\end{figure}
\subsection{Database}
Creating the database for the purpose of the server is quite easy. In App\_Data folder in the FlightService project contains a file named Db\_Create.sql. This file helps in creating the proper definition of tables. At first we should create a database and name it "Flights". Then run the query in the file. In the same folder we can also find an excel file Flights.xls. There are artificial data of connections and prices. Those data should be imported to the database "Flights" and to the table "dbo.Flights".\\
Finally, to connect the program to the existing database, we need to add a proper connection string in Web.config file of the FlightService project. In connectionStrings section, there is one item already added, We change its connectionString property to whatever our setting in the database are. My current connection string is 
\textsc{"Server=KAROLINA-PC; Database=Flights; Trusted\_Connection=True;"}\\
where:
\begin{itemize}
\item \textbf{Server} is the name of the computer,
\item \textbf{Database} is the name of the database,
\item \textbf{Trusted\_Connection} means, that there is no password set and it is a local connection, Windows Authentication only.
\end{itemize}
\subsection{Client}

After installing all necessary and recommended software on your computer, we have to open our source code. We can do it by clicking on File -$>$Import, under Android we select Existing Android Code Into Workspace, click Next. On the Next window please select Browse… select our folder, which contains our project and press OK. Make sure that you press Select All option, and now we can finish importing option by pressing Finish. As we can see, on the left hand side, under Package Explorer we can see our project. To see main classes of our project we have to expand TripAdvisorClient, expand src and expand the package com.example.tripadvisorclient and there they are. 


\includegraphics[scale=0.8]{graphics/1g.png} 

To run the application we need to select TripAdvisorClient and press Run menu at the top and again Run or simply Ctrl+F11. After waiting a few seconds, an emulator will start. We are using AVD for Nexus by Google, showing how it would run on that device. As in normal Android phone, we first have to unlock it to see our running application. The rest is included in the video we have made of how to use our application.

\includegraphics[scale=1]{graphics/2g.png}

To run the client on the phone, we need to export our source code to Android Application. In order to do that we need to click on File-$>$Export. Select Export Android Application and press Next. We Browse and select our project and press Next again. We can see that the next step is to create a Keystore selection. Probably this will be the first time you hear about this, so creating a new keystore seems like a good idea. We need to select a location of the keystore (might be anywhere you like) and we need to create and confirm the password. Afterwards, we can press Next. Next is the Key Creation – we need to fill up all four lines at the top and at least one below the line. On the next window, we have to select the destination of APK file, which is the file we will download on our phone. After pressing Finish, we need to find this APK file, connect our phone by USB (and select an option on the phone to be used a Storage Usage) and copy that file to a folder so that we can easily find it on our phone. Assuming that our phone contains already AppInstaller, we unplug the device from the computer and we start this application. We browse through the folders and find APK file that we downloaded. We click on it and select the Install option. After a few seconds, our application is ready to be used on our Android phone.


\makestatement
\end{document}
